home *** CD-ROM | disk | FTP | other *** search
/ Developer CD Series 1997 January: Mac OS SDK / Dev.CD Jan 97 SDK2.toast / Development Kits (Disc 2) / OpenDoc Development Framework / ODF-Interest Archive / March 96 / Re Initializing an Extension.6 < prev    next >
Encoding:
Internet Message Format  |  1996-12-03  |  4.6 KB  |  [TEXT/ttxt]
  1. Subject:     Re: Initializing an Extension
  2. Sent:        3/12/96 9:55 AM
  3. Received:    3/12/96 8:57 AM
  4. From:        Greg Friedman, friedman@cognosis.com
  5. Reply-To:    ODF-Interest@CILabs.ORG
  6. To:          OpenDoc Development Framework Discussion List, ODF-Interest@CILabs.
  7.  
  8. >The following questions and scenario might be [complex] so I hope
  9. >I state the problem clearly.
  10. >
  11. >I have created suite of SOM classes that implement a rich, hierarchical
  12. >data [model.]  The scheme is this; a thing called a Property has
  13. >a name and a value.  A value can be an integer, real, string, SOM call
  14. >[it looks pretty much like Property SOMClass:SOM Method( in Property
  15. >parameterList )], list of Properties, or an enumeration [of strings.]
  16. >
  17.  
  18. Bernhard,
  19.  
  20. Sorry for the delay in responding to your question, but I wanted to give it
  21. some thought.  Jim and I spoke about it yesterday, and here's what we came
  22. up with.
  23.  
  24. You want to extend the functional API of a part. The best way to do this is
  25. via an extension. Remember that an extension "extends the API" of the
  26. object that creates it. Attempting to circumvent extensions by extending
  27. the APIs of objects defined by OpenDoc by subclassing is going to cause you
  28. and anyone that tries to use your API headaches.
  29.  
  30. If I understand your message correctly, it sounds like once you've begun a
  31. session with a part, you want to navigate the part's content model. You
  32. want the content model to appear to be a tree of objects, each node of
  33. which has properties that can be accessed by some other part. External
  34. parts might be interested in the state of a specific property, and need to
  35. be notified if it changes.
  36.  
  37. At first glance, it looks like you are describing much of what the
  38. scripting implementation in OpenDoc provides. OpenDoc scripting is based on
  39. the Apple Event Object Model. Every object inside of a part is represented
  40. as an object that has properties and elements. Semantic events can be
  41. constructed that request property information and that access contained
  42. elements. My first suggestion is that you read Chapter 9 in the OpenDoc
  43. Programmer's Guide, "Semantic Events and Scripting", and determine whether
  44. or not you can accomplish your goal with scripting. You'll note, by the
  45. way, that scripting is implemented as an extension. One additional benefit
  46. of using scripting is that you will not only expose your data to parts that
  47. know how to talk your language, but you will also expose your data to a
  48. scripter who wants to script control of your part.
  49.  
  50. Scripting solves the data exposure problem, but it doesn't provide a
  51. built-in mechanism for notification. If, for this reason or others, you
  52. decide that you don't want to use scripting, you can accomplish your design
  53. with SOM objects as your message suggests. I strongly suggest that your
  54. design provide access to the root object of a part via an extension. Your
  55. extension API might be as simple as a single method called
  56. "GetRootInspectableObject".
  57.  
  58. The root object can then provide access to its contained objects. As I
  59. mentioned above, anything you do here will look a lot like a scripting
  60. implementation. To give you a sense of what I mean by this, I'll give you a
  61. peek at what the scripting implementation in ODF 1 looks like.
  62.  
  63. In ODF 1, any object can be made scriptable. This is accomplished by mixing
  64. a new class, FW_MScriptable, into an object. Once an object is scriptable,
  65. it has the following functionality:
  66.  
  67. Semantic access to contained elements. Elements can be accessed by a large
  68. set of semantic forms (by index, name, relative position, unique id,
  69. satisyfing a test, etc.) ODF provides much of the default access
  70. functionality.
  71.  
  72. Accessible and mutable properties. Built-in support for undo of property
  73. mutation. You write code to handle getting and setting a property. When a
  74. semantic "Set Property" event occurs, ODF invisibly gets the old property
  75. state, and creates an undoable command that can undo/redo the property
  76. change.
  77.  
  78. Creation of object specifiers. Any scriptable object can create a data
  79. structure understood by the OpenScriptingArchitecture that describes its
  80. location in the object hierarchy.
  81.  
  82. Handling of semantic events.
  83.  
  84. Etc, etc.
  85.  
  86. You may decide to do something like this, but have each object factory a
  87. SOM object that provides access to its properties. You still have to deal,
  88. on your own, with the fact that after an SOM object has been created, the
  89. base object that created it might go away. You also have to deal with
  90. notification. The best approach will be to use SOM. This will require the
  91. interested object to be a SOM object of a specific class.
  92.  
  93. Hope this helps,
  94.  
  95. Greg.
  96.  
  97.  
  98. ___________________________________________________________
  99. Greg Friedman        ODF Engineering         Apple Computer
  100.  
  101.